A debugger is a software tool that allows software developers to debug software programs, generally written in a high level programming language such as, for example, Java or C++, and enabling the developer to review or analyze the state of a software program at different points in its execution. Typical debug operations that can be performed by the developer include the opportunity to set/clear breakpoints, single-step, resume and view/edit variables. Debuggers are typically offered as one tool or part of an integrated development environment (IDE) that in turn is integrated with a runtime environment, for debugging the software program under development.
Business processes, which may also be referred to as business flows or workflows, provide a level of abstraction above programming languages such as Java or C++, making them easier for non-programmers to use to describe desired processing within a particular business process. An example language used to define business processes is the Business Process Execution Language (BPEL), which is an XML-based executable language for specifying orchestration between web services that comprise a business process. A BPEL Debugger allows developers to debug a BPEL business process for execution in a BPEL runtime environment.
FIG. 1 shows an illustration of a typical networked computing environment. As shown in FIG. 1, a typical networked computing environment can include a plurality of clients 100, such as Client 1, Client 2, and Client N connected to a network 102, such as the Internet. The clients can be, for example, personal computers, workstations, mobile computing devices, or any other networkable device. Also connected to the network are a plurality of servers 104 such as Server 1, Server 2, and Server N. These servers can include application servers and web servers which provide services in response to requests that are received over the network from the clients or other servers or services. A developer system 106 can provide a software developer with access to the network to create, modify, and/or deploy business processes, which can then be utilized by the plurality of clients. The developer can deploy the business processes to a production server 108, which is typically a computer server system that stores and executes the business processes. The production server can access additional business processes stored in a database 110. The production server can receive service requests from the plurality of clients, or the plurality of servers, and execute an appropriate business process. Execution of the appropriate business process can include invoking one or more web services offered by the plurality of servers.
FIG. 2 shows a diagram illustrating a typical interaction between a developer system and a production server. As described above, developer system 106 can access production server 108 to create, modify, and/or deploy business processes. Developer system can be a personal computer, workstation, mobile device, or any networkable device. As shown in FIG. 2, the developer system can include a computer readable medium 202 and processor 200 operating thereon, in addition to an integrated development environment (IDE) 204 and an internet browser 206. The developer system can include tools for creating and modifying the business processes. These tools can include a debugger which enables the developer to test, or debug, business processes, by controlling the execution of the business processes and providing input from the developer at various stages of execution. Additionally, the developer system can include an internet browser 206 which a developer can use to access a web interface for a business process management console at a production server. Such a business process management console can be used to deploy & manage business processes running on the production server, including instantiation and runtime debugging of business processes.
When a developer has created a business process, the developer can deploy the business process from the developer system to the production server. As shown in FIG. 2, the production server can similarly include a computer readable medium and processor operating thereon. Business processes can be written in any appropriate language, such as BPEL. The production server can also store business processes, either as source code or compiled code, locally on the computer readable medium, on database 110, or on any other data store accessible to the production server. When the production server receives a service request, the production server can retrieve an appropriate business process, and compile it if necessary. The compiled code is then passed 214 to a business process engine for execution. The business process engine can be a BPEL engine 214 or other appropriate engine, and the production server can include a BPEL compiler 212 or other suitable compiler.
As with any software under development, thorough testing can be used to ensure a stable and reliable product that performs as expected and provides the functionality desired by the developer and the end users. As described above, debugging is a common process used to test software both prior to and after deployment. A debugger can be provided as part of an IDE or as a standalone product and can be executed locally or accessed remotely, such as via a web service. A debugger can be used to debug code at the source code, or business process level (such as BPEL code) or at the compiled code level (such as the underlying Java, C#, or other lower level code). As also described above, debuggers provide a means for a developer to test business processes, by executing activities one at a time sequentially using single-step execution, and presenting options to the developer at various points during execution. However, business processes do not always proceed sequentially, and some activities can include parallel branches, which cannot be reliably tested by the standard single-step debugging technique. This is the general area that embodiments of the invention are intended to address.